C6 — 内容与媒体咨询工作室 · 场景指引

一、场景概述

本场景是 ZY AI Native Engine 长周期业务场景测试六张核心故事卡之一，编号 core-C6，定位为 evo 组织进化全链路总压测 与 会议导入及分层知识库 的联合演练场。场景模拟一家品牌内容与增长代运营工作室，从一位全能顾问加一名 AI 助手起步，通过承接客户内容咨询订单，逐步沉淀方法论，最终成长为拥有策略、内容、客户、职能四大组共十五个 AI 角色的规模化组织。整个过程横跨三个阶段——T1 生存期（1-3 编制，首单交付与方法论沉淀）、T2 扩张期（4-10 编制，三家客户并行与组织裂变）、T3 规模化期（11-30 编制，部门建制与可回退可审计）——完整覆盖了 evo 组织进化引擎从阶段感知、缺口检测、扩编建议、一键采纳、上岗测试、进入调度、阶段切换到组织回滚的全部核心链路。

与 C1 跨境电商侧重端到端闭环、C2 预测市场侧重资金安全不同，C6 的核心价值在于验证平台能否支撑一个知识密集型服务场景的完整生命周期：从 kickoff 会议的转写文本导入，到纪要与待办自动提取，再到知识入库时的人工确认与冲突检测，最终将会议产出转化为可执行的任务。这条「会议 → 纪要 → 待办 → 任务」的链路是知识沉淀飞轮的第一推动力，也是本场景区别于其他五张故事卡的独特压测面。与此同时，随着客户数量从一家增长到三家，系统需要自动感知负载缺口、产出扩编建议、在人工一键确认后完成新角色的上岗并立即纳入调度——这条 evo 全链路是本场景的命脉所在，也是 FIX-004 一票否决项的判定焦点。

在 D1 至 D3 的实际测试中，我们已经取得了若干关键结论：冷启动六步（注册 → 建公司 → 建项目 → 自挂实例 → 策略确认 → 组织起步）的真实 UI 路径全部通过；evo 的「一键扩编 → 新角色下一 tick 被派活」闭环在 C6 形态下实测打通（FIX-004/A 销号）；但 evo 的入口腿——阶段感知与缺口检测——在新建项目上因 project_config.config 为 NULL 导致 JSON 解析错误而恒返 500（ISSUE-W4-14），该缺陷在 D2 修复后恢复。D3 进一步揭示了批量扩编无规模闸门（ISSUE-W4-51）、跨分类串模板（ISSUE-W4-52）、成熟度门两条路径不一致（ISSUE-W4-53）以及拒绝通道不写冷却期（ISSUE-W4-49）等深层问题。这些发现不仅指导了后续的修复优先级，也为本场景指引的编写提供了实证基础。

本场景还特别关注知识污染的拦截能力：在品牌资料包中预埋一条与客户既有口径矛盾的「污染知识」，验证系统在知识入库环节能否通过冲突检测将其拦下，防止错误信息进入分层知识库后影响后续所有 AI 产出。这一演练直接关联到故事卡中「知识入库防污染」的 P1 建议项，也是三权分立验收体系在知识管理维度的延伸。通过会议导入、知识入库、任务转化、组织扩编、阶段切换、组织回滚这六大核心流程的联合压测，C6 场景为平台的组织进化能力与知识管理能力提供了一次全面而深入的压力检验。

二、场景目标与主战场能力

C6 场景的核心目标可以概括为三个层次：第一层验证 evo 组织进化引擎在全生命周期中的可靠性，包括阶段感知的准确性、缺口检测的有效性、扩编建议的合理性、一键扩编的原子性以及新角色进入调度后的实际产出；第二层验证会议导入与分层知识库在知识密集型服务场景中的实用性，包括会议转写文本的纪要提取质量、待办事项的任务转化率、知识入库的冲突检测能力以及公司级与项目级知识的分层检索命中率；第三层验证组织在规模化后的治理能力，包括部门级阿米巴核算的准确性、SLA 超时升级链的时效性、跨客户资源冲突的仲裁留痕以及组织回滚后任务零丢失的原子性保证。

2.1 主战场能力矩阵

本场景必需的能力涵盖以下六大模块，每一模块都有明确的 API 路径与数据库落点：

2.2 FIX-004 一票否决项

FIX-004 的完整取证要求五线交叉验证：① auto_ops_tasks.role_id 绑定数；② auto_ops_rounds 轮次归因数与首个 done 轮号；③ token_billing_records.role_id 计费归因行数；④ 被绑任务的 round_count 累计；⑤ auto_ops_progress.task_summary 非空行数（产出摘要）。锚点取新岗创建前最后一轮，计算首调轮与锚点的差值 Δ，判据为 Δ ≤ 3 轮。D3 实测中 8 个新岗仅 1 个走产品自动通道（Δ=4，仍差 1 轮），5 个依赖人工点名（Δ=18~38），2 个整窗零消费。

2.3 组织裂变与回滚

组织裂变是本场景最具特色的压测面。从 T1 的「1 人 + 1 AI 全能顾问」到 T2 的「1 人 + 15 AI 四组分工」，组织需要经历多次扩编与阶段切换。每一次扩编都必须满足三个条件：缺口检测产出合理建议（含成本增量与证据）、人工一键确认后新角色立即上岗、新角色在 3 轮内被实际调度并产生执行痕迹。阶段切换则需要验证成熟度门的执行一致性——在 D3 测试中发现，建议腿要求成熟度达标才能产出 stage_upgrade 建议，但执行腿的 ApplyTransition 完全不检查成熟度，导致在 maturity=not_reached 的状态下仍能一路从 startup 切到 scale。

组织回滚是 T3 的核心演练项。通过 POST /org/advice/:id/rollback 或 POST /org/transition/rollback 触发回滚后，系统必须恢复旧的组织快照，删除扩编角色并解除调度绑定，同时在 change_logs 中留痕，且保证任务零丢失（回滚前后未完成任务集 diff = ∅）。D3 测试中发现 UI 面板对 scale_out 类型不渲染「回滚扩编」按钮（ISSUE-W4-35），这意味着在 UI 修复前，组织回滚只能通过 API 路径执行，计为一次人工干预。

三、预置条件与环境配置

3.1 项目基础设定

C6 场景的测试项目命名为 lts_c6_media（D1-D3 实际使用的项目 ID 为 1113，公司 ID 为 972），运行模式设定为「全自动」（run_mode=full_auto，D1 实际使用 semi_auto 作为测试口径），总预算 ¥7,000，AI 运行预算 ¥2,500，平台余额 ¥1,500。项目类型选择「内容」（type=content），这将影响引导流中的业务背景模板与岗位推荐集。实例绑定到本机 127.0.0.1:8090 的 project-server，通过 HMAC 认证完成自挂。

3.2 会议资料与品牌包

C6 场景的核心输入数据包括三部分：kickoff 会议转写文本、客户品牌资料包以及方法论 SOP 模板。kickoff 会议转写文本模拟首次客户对接会议的完整录音转写内容，包含客户业务背景、目标受众画像、品牌调性要求、内容交付节奏与验收标准等关键信息。该文本通过 POST /projects/:id/meetings/import-text 或 POST /projects/:id/meetings/import-file 导入系统，由 AI 自动提取纪要与待办事项，并存储到 meetings 与 meeting_action_items 表中。品牌资料包包含客户的视觉规范、历史内容样本、竞品分析摘要等，通过边缘客户端上传或 API 直接导入知识库。

在 D1-D3 的测试中，会议导入与知识入库流程尚未实际执行（knowledge_documents=0），这被列为 D4 的最高优先事项。完整的会议导入流程应当包含以下步骤：上传转写文本 → AI 生成纪要与待办 → 人工审核纪要准确性 → 将待办 convert 成任务（POST /projects/:id/meetings/:meeting_id/action-items/:item_id/convert）→ 验证每条任务携带原始片段回链。这一流程的完整性直接影响「纪要 → 任务转化率 100%」这一 T1 核心判据。

3.3 污染知识演练

在品牌资料包中，需要预埋一条故意与客户既有口径矛盾的「污染知识」。例如，客户在 kickoff 会议中明确要求「所有案例数据须可溯源」，但在品牌资料包中插入一条「案例引用无需标注数据来源」的规范。这条污染知识应当在知识入库的 needs_review 环节被冲突检测机制拦截，系统需要识别出它与已入库的会议口径存在矛盾，并强制要求人工确认。

如果系统未能拦截这条污染知识（D1-D3 中因知识库流程未执行而无法判定），则记录为缺陷并降级为观察项。冲突检测的实现依赖于 knowledge_documents 表中的 needs_review 状态链，以及知识清洗分块向量化过程中的语义相似度比对。在取证时，需要验证 knowledge_documents 表中该条记录的状态是否停留在 needs_review 而非直接进入 active，同时检查 change_logs 中是否有对应的冲突检测留痕。

四、T1 生存期操作指引

T1 生存期的核心目标是完成首单交付并开始方法论沉淀。编制为 1 人 + 1 AI（全能顾问），需要验证的关键判据包括：自主率 ≥ 40%、人工干预 ≤ 16 次、单位交付 token 成本 ≤ ¥60、人工分钟 ≤ 40/交付、纪要 → 任务转化率 100%、首次交付被客户接受、知识库可被后续任务 RAG 命中。

4.1 UI 全链路路径

T1 的完整 UI 操作路径如下，每一步都需要截图取证并记录网络请求：

1. 登录：访问 http://localhost:5176/login，输入 lts_c6_*@test.com / test123，点击登录，验证跳转到 /dashboard 全局面板。
2. 建公司：全局面板点击「新建公司」，填写名称 LTS-C6 内容媒体工作室，确认创建。验证 companies 表新增一行 status=active。
3. 建项目：进入公司后点击「新建项目」，走三步向导——选择类型「内容」、设定运行模式「全自动」/「半自动」、填写总预算 ¥7,000 与 AI 运行预算 ¥2,500。确认页回显预算金额。验证 projects 与 project_budgets 表落库。
4. 引导流：进入项目后自动触发引导流四步——业务介绍（粘贴品牌背景）→ 组织（建 1 管理者 + 2 员工）→ 定义（任务模板与交付标准）→ 启动。验证 guided_sessions 表 strategy_confirmed=t。
5. 会议导入：在知识库域点击「会议导入」，上传 kickoff 会议转写文本（或调用 API）。等待 AI 生成纪要与待办。验证 meetings 与 meeting_action_items 表有记录。
6. 知识入库：对 8 条待入库知识逐条审核（含 1 条污染知识）。在 needs_review 弹窗中核实无客户机密、与既有口径不冲突后批准入库。污染知识应被冲突检测拦下。
7. AI 出策略与撰稿：启动 auto-ops 引擎（POST /autoops/start 或 UI「启动」按钮），观察轮次自动推进。AI 自主产出策略报告、选题库、撰稿内容。
8. 验收与交付：独立验收 Agent 对撰稿内容进行审核（acceptance_records），人工在审批弹窗中批准 2 次交付外发（邮件通道，走 connector_audit_logs pending → executed）。1 次客户需求变更后需人工确认更新后的 done_when。

4.2 会议导入流程详解

会议导入是 C6 场景最核心的知识沉淀入口，完整流程分为五个阶段：

阶段一：上传转写文本

通过 UI 的「会议导入」入口或 API POST /projects/:id/meetings/import-text 上传 kickoff 会议的转写文本。文本应包含完整的会议对话内容，涵盖客户需求描述、品牌调性讨论、交付节奏约定、验收标准确认等关键议题。上传后系统自动调用 LLM 进行纪要提取，生成结构化的会议纪要（包含议题摘要、关键决策、待办事项三部分）。

阶段二：审核纪要与待办

AI 生成的纪要需要人工审核确认准确性。在 UI 中查看纪要内容，核对关键决策是否与会议实际内容一致，待办事项是否完整覆盖了会议中约定的后续动作。如有遗漏或错误，可手动编辑修正。审核通过后，纪要状态从 draft 变为 confirmed。

阶段三：待办转化为任务

对每一条待办事项（存储在 meeting_action_items 表中），调用 POST /projects/:id/meetings/:meeting_id/action-items/:item_id/convert 将其转化为 auto_ops_tasks 表中的正式任务。转化时必须验证每条任务携带原始片段回链——即任务的描述中应包含对应会议原话的引用，防止需求漂移。判据为「纪要 → 任务转化率 100%」，即所有 meeting_action_items 都必须建立对应的任务。

阶段四：任务进入调度

转化完成的任务进入 auto-ops 调度队列。引擎在下一个 tick 按轮前角色解析机制将任务分配给最合适的角色实例。在 T1 阶段，由于组织只有 1 个管理者 + 2 个员工（seo_expert + copywriter），大部分任务会分配给 copywriter 或 general_executor。验证点为 auto_ops_tasks.role_id 非空且 auto_ops_rounds 中出现该任务的执行记录。

阶段五：产出与验收

任务执行完成后，独立验收 Agent 对照 done_when 产出验收结论。通过的任务标记 finished=true 并回写 finished_at（D3 已验证 pass → 任务终态回写生效，delta_ms ≈ 1ms）。redo/reject 的任务进入返工队列，等待下一轮调度。

4.3 知识入库人工确认（8 条含污染知识拦截）

知识入库是知识沉淀的第二条路径。品牌资料包中的文档经过清洗、分块、向量化后进入 knowledge_documents 表，但状态为 needs_review，需要人工逐条确认后才能变为 active 供 RAG 检索使用。T1 阶段需要确认 8 条知识文档，其中包含 1 条故意预埋的污染知识。

4.4 事件注入（client.change）

T1 阶段需要注入两类关键事件：客户需求变更与首笔项目款入账。客户需求变更事件通过 harness 的 ingest-event.mjs 脚本或直接调用 POST /api/v1/events 注入，完整 JSON 如下：

{
  "source": "email",
  "event_type": "client.change",
  "title": "客户需求变更：案例数据须可溯源",
  "content": "{\"client\":\"A\",\"section\":\"语气\",\"new_done_when\":\"案例数据须可溯源\",\"original\":\"无特殊要求\"}",
  "priority": "important"
}

该事件注入后，期望系统产生以下反应：① events 表新增一行，status 从 pending 变为 processed；② 事件→Agent 协调器将该事件分配给相关角色（event_assignments 表新增记录）；③ 相关任务的 done_when 字段需要人工确认更新（RACI 人工节点 human_task_nodes 新增一条审批记录）。需要注意的是，D1-D3 测试中事件→派单链路存在 event_assignments=0 的问题（ISSUE-W4-26），事件能被接收和分类但不会被自动分配给 Agent，这一缺陷需在 D4 复测。

首笔项目款入账事件通过 ingest-event.mjs --type payment 注入，自动附带项目账本收入分录（project_ledger 表），验证双线账本的虚拟核算入口。

五、T2 扩张期操作指引

T2 扩张期的核心目标是实现三家客户并行，组织从一人全能裂变为有分工的小所。编制从 1+1 扩展到 1+15，新增四组：策略组、内容组（撰稿 ×3/校对/视觉）、客户组（经理 ×2/交付）、职能组（财务/内审/知识管理）。核心判据包括：自主率 ≥ 65%、人工干预 ≤ 10 次/周、单位交付 ≤ ¥40、扩编后毛利不降、SOP 复用使返工率降 ≥ 30%。

5.1 三家客户并行

新增两家客户的理想路径是通过「新项目 + 预算事件」实现客户级隔离（每个客户一个独立项目，天然等价于客户级熔断）。但在 D3 测试中，由于 grant active 已达上限（10/12）且产品无客户实体写入口（营销面板「潜在客户」页新增按钮数 = 0），实际采用降级方案：在 lts_c6_studio 项目内建两条客户任务组（北极星健身会员留存、云澜咖啡本周新品），以任务级隔离代替项目级隔离。这一降级方案的局限性在于：一家客户超支会暂停整个项目循环（BudgetController 以 projectID 为键），无法实现「不牵连其他」的客户级独立熔断。

5.2 组织裂变与扩编 5 岗

组织裂变由 evo 的缺口检测驱动。当未完成任务数超过阈值（默认 20），系统通过 POST /org/stage/sense 触发阶段感知，DetectGaps 产出扩编建议（growth_advice 表 type=scale_out 或 role_add），建议中包含角色类型、成本估算与负载证据。人工在组织面板点击「确认」→「确认采纳」，调用 POST /org/advice/:id/accept 完成一键扩编。

D3 实测中，通过 UI 一键扩编与两次阶段切换批量扩编共新增 8 个岗位（超过故事卡要求的 5 岗），组织从 5 → 13 实例。但暴露了三个关键问题：① 批量扩编无规模/成本闸门（ISSUE-W4-51），一次点击越过目标带 30%；② 跨分类串模板（ISSUE-W4-52），内容工作室被装配了电商/制造业画像；③ 扩编产出的实例技能白名单全空（ISSUE-W4-34），capabilities 13/13 全为 {}。

5.3 驳回过早扩编与冷却期验证

故事卡要求「驳回 1 条过早扩编并验证冷却期不重复打扰」。D3 通过双臂对照实验验证了这一判据：对同一条 pending 建议分别执行「拒绝」与「暂缓 7 天」操作，然后连续两圈点击「重新评估」观察同 (type, role_key) 键位是否重产新卡。

实验结果：「暂缓」臂——两圈零重产，cooldown_until 写入 7 天后的时间戳，冷却期机制生效；「拒绝」臂——两圈后同键重产 1 行新卡（拒绝后 3 秒即重产），cooldown_until 为空。缺陷精确定位在拒绝通道不写冷却期（gap.go:640-657），已建 ISSUE-W4-49。主控裁决：判产品缺陷（P1），故事卡 T2-6 判据优先。修复批须把在册单测 TestStory49 的断言改严（冷却期内不得重产、到期后方可重产）。

六、T3 规模化期操作指引

T3 规模化期的核心目标是验证部门建制下的治理能力，包括 SLA 超时升级链、跨客户冲突仲裁、阿米巴核算与组织回滚。判据包括：自主率 ≥ 75%、人工升级 ≤ 6 次/周、单位交付 ≤ ¥28、人效比 ≥ T1 的 3 倍。

6.1 关键人休假 → SLA 超时升级链

注入关键人休假场景后，系统需要触发 SLA 超时升级链。具体验证路径为：审核人节点在 escalate_at 时刻到达后未被处理，SLASweep（internal/autoops/human.go:1508-1524）扫描到该节点后自动推进升级链（审核人 → 负责人），同时通知链上下位。验证要点包括：

• human_task_nodes 表中 escalation_level 字段递增
• notifications 表中出现升级通知记录
• 升级后新审批人能够正常处理该节点

D1 判据修正中已确认 SLA 升级链在码面生效（两把 sweeper 真在跑，ticker 30s/60s），但需注意前置条件：human_task_nodes 中节点的 escalate_at 必须非空且链已建，否则读到的是「节点不在扫描面」而非「升级链失效」。T3 注入超时事件前，必须先确认节点 escalate_at 非空。

6.2 跨客户并发冲突仲裁

当三家客户同时需要同一角色（如 copywriter）的服务时，会产生跨客户资源争用。系统需要通过 arbitration_cases 表记录仲裁过程，decision_logs 表留痕决策依据。验证要点为：仲裁留痕完整（不互相覆盖）、被仲裁的任务在下一轮得到优先调度、仲裁结论可追溯到 decision_traces 表。

6.3 部门级阿米巴核算

阿米巴核算通过 amoeba_daily_stats 表实现岗位级成本与产出的独立核算。D1 判据修正中发现，SaveDailyStats 与 AggregateDailyStats 在生产代码中零调用点，amoeba_daily_stats 表的数据全部来自 e2e 夹具直接 INSERT。因此，阿米巴/人效类判据降级为观察项，成本取证改走 GET /autoops/billing?group_by=role|task|round（源表 token_billing_records）。

岗位维成本可用 ?group_by=role 取得，客户维只有当客户 = 项目时可取 ?project_id=。单位 token 附加值的计算公式为：全项目累计计费 ÷ acceptance_records.verdict='pass' 条数。D3 实测值为 ¥0.606782 ÷ 2 = ¥0.303391/条（样本仅 2 条，不外推）。

6.4 组织回滚演练

组织回滚是 T3 最重要的演练项。通过 POST /org/advice/:id/rollback 触发回滚后，系统需要完成以下原子操作：

1. 将目标角色实例标记为软删除（agents.deleted_at 非空）
2. 解除该角色与所有任务的调度绑定（auto_ops_tasks.role_id 清空或重新分配）
3. 在 change_logs 中写入回滚操作记录（action=rollback）
4. 在 decision_traces 中留痕回滚决策
5. 保证未完成任务零丢失（回滚前后 auto_ops_tasks 中 finished=false 的任务集 diff = ∅）

回滚验证的完整取证流程为：① 回滚前拍快照（记录当前 agents 表全量、auto_ops_tasks 未完成任务集、auto_ops_rounds 最大 round_no）；② 执行回滚 API；③ 回滚后拍快照（验证 agents 软删、change_logs 留痕）；④ 对比回滚前后未完成任务集（diff 必须为空）；⑤ 继续运行 3-5 轮，验证引擎不因回滚而异常停止或跳过任务。

七、验收判定表

以下为 C6 场景三阶段的验收判定标准，基于 D1-D3 实测数据给出当前状态评估：

八、取证口径

C6 场景的取证遵循「页面 + 网络 + psql」三重交叉原则，单层不定论。以下为各核心验证项的取证数据库表与关键 SQL：

8.1 会议导入与知识沉淀

-- 会议纪要与待办
SELECT m.id, m.title, m.status, count(ai.id) AS action_items
FROM meetings m LEFT JOIN meeting_action_items ai ON ai.meeting_id = m.id
WHERE m.project_id = '1113' GROUP BY m.id;

-- 知识入库状态链
SELECT status, count(*) FROM knowledge_documents
WHERE project_id = '1113' GROUP BY status;

-- 知识分块向量化
SELECT count(*) FROM knowledge_chunks
WHERE document_id IN (SELECT id FROM knowledge_documents WHERE project_id = '1113');

8.2 evo 组织进化全链路

-- 扩编建议状态链
SELECT type, role_key, status, count(*),
       count(*) FILTER (WHERE cooldown_until IS NOT NULL) AS with_cooldown
FROM growth_advice WHERE project_id = '1113' AND deleted_at IS NULL
GROUP BY 1, 2, 3;

-- 角色实例三面（能力/职责/红线）
SELECT agent_id, name, role,
       CASE WHEN coalesce(responsibility_boundary,'') = '' THEN '空' ELSE '有' END AS resp,
       capabilities::text AS caps
FROM agents WHERE project_id = '1113' AND deleted_at IS NULL;

-- 组织变更日志
SELECT action, operator, count(*) FROM change_logs
WHERE project_id = '1113' GROUP BY action, operator ORDER BY action;

-- 角色版本快照
SELECT count(*) FROM role_versions WHERE project_id = '1113';

-- 决策追踪
SELECT count(*) FROM decision_traces WHERE project_id = '1113';

8.3 调度与计费归因

-- 新角色调度验证（FIX-004 五线交叉）
-- 线 1：任务绑定
SELECT t.role_id, count(*) FROM auto_ops_tasks t
WHERE t.project_id = '1113' AND t.role_id = ':agent_id' GROUP BY 1;

-- 线 2：轮次归因
SELECT r.round_no, r.status, r.cost FROM auto_ops_rounds r
JOIN auto_ops_tasks t ON t.task_id = r.task_id
WHERE t.project_id = '1113' AND t.role_id = ':agent_id' ORDER BY r.round_no;

-- 线 3：计费归因
SELECT count(*), round(sum(cost)::numeric, 6) FROM token_billing_records
WHERE project_id = '1113' AND role_id = ':agent_id';

-- 线 4：任务累计轮
SELECT t.name, t.round_count FROM auto_ops_tasks t
WHERE t.project_id = '1113' AND t.role_id = ':agent_id';

-- 线 5：产出摘要
SELECT count(*) FROM auto_ops_progress
WHERE project_id = '1113' AND coalesce(task_summary, '') <> '';

8.4 预算与账本

-- 预算状态
SELECT ai_budget, ai_used, total_budget, warned, meltdown, ai_meltdown
FROM budget_states WHERE project_id = '1113';

-- 计费分桶（验证无估算行）
SELECT CASE WHEN log_ref LIKE 'round:%' THEN 'round:'
            WHEN log_ref LIKE 'direct:%' THEN 'direct:'
            WHEN log_ref LIKE 'est:%' THEN 'est:'
            ELSE 'other' END AS bucket,
       count(*), round(sum(cost)::numeric, 6)
FROM token_billing_records WHERE project_id = '1113'
GROUP BY 1 ORDER BY 1;

九、附录：环境信息

9.1 端口映射

9.2 关键表清单

project_server 库

ai_native_engine 库（platform）

9.3 harness 脚本用法

C6 场景使用的 harness 脚本位于 wiki/long_term_testing/harness/，采用 Node ESM（.mjs）编写，零第三方依赖。

drive.mjs — 推进/观察 auto-ops

# 观察轮（只读采集 + 快照 + 台账，零副作用）
node drive.mjs

# 触发 review（轮询等 auto_ops_rounds 最大 id 增长）
node drive.mjs --mode review --wait 240

# 指定场景标签
node drive.mjs --scenario C6 --label "T1-D4"

ingest-event.mjs — 外部事件注入

# 注入客户需求变更事件
node ingest-event.mjs --type email.reply --scenario C6 \
  --subject "需求变更" --text "案例数据须可溯源"

# 注入项目款入账（自动附带项目账本收入分录）
node ingest-event.mjs --type payment --scenario C6 --amount 5000

# 续跑：重投未成功的事件
node ingest-event.mjs --replay-pending

approve.mjs — 审批模拟器

# 审批队列（human + acceptance + connector）
node approve.mjs --scenario C6

# 只出判定，零副作用
node approve.mjs --dry-run

# 端到端自证
node approve.mjs --selftest

幂等约定

事件键 = <SCENARIO>/<YYYY-MM-DD>/<NNN>，文件即锁。同键已 fed 则不重复投喂。审批幂等键 <SCENARIO>/<YYYY-MM-DD>/appr-<queue>-<id>，同键已 ok 则跳过。drive 幂等键允许同日多行（观察性质）。

断点续跑

1. 读 STATUS.md（战役状态板）→ 当前位置与拦路虎
2. 读 ledger/ops-log.md 尾部 20 行 → 最近操作
3. 读 ledger/state.json → 非 fed 的事件 --replay-pending
4. node lib.mjs 复检三端 + token + 两库
5. 按故事卡排当轮：drive → ingest-event → 引擎跑 → approve → 记报告